In a network using Internet Protocol (IP) transport, IP Multimedia Subsystem (IMS) is regarded as a basic infrastructure for delivering various multimedia services. The 3rd Generation Partnership Project (3GPP)/3GPP2 standards define the IMS, and the TISPAN (Telecoms & Internet converged Services & Protocols for Advanced Networks) standard defines the fixed network IMS.
Those standards suggest resource reservation procedures in accordance with characteristics of an access network. The 3GPP IMS defines the resource reservation procedure including two options of a precondition and a non-precondition.
The precondition option allocates the resources for communications prior to the call setup through one INVITE request transmission, and the non-precondition option allocates the resources for the call setup through two INVITE request transmissions.
The 3GPP standard defines a call flow based on the precondition to complete the resource reservation prior to the session activation and recently defines the non-precondition based call flow based without applying the precondition (for services not requiring real-time QoS). However, since the concept of the precondition is absent in the wireline network, the precondition is not requested in the call setup.
To allow the call setup between a wireless terminal and a wired terminal, when the wireless terminal also provides the call setup using the non-precondition call flow without applying the precondition, it seems that the smooth call setup is carried out between the wireline network and the wireless network. However, in this situation, the call setup is impossible because of the difference of the call flows of the two networks. When the non-precondition is adopted, due to the characteristic of the wireless network which reserves the wireless resource, the terminal attempting voice communications needs to send the INVITE request two times.
In the wireless network, what is needed is a method for reserving the resource of the wireless network by transmitting one INVITE request and activating the reserved resource by sending the re-INVITE request after the reservation so that the terminal can use the reserved resource.
The wireline network conducts the reservation and the permission of the wired resource by means of one INVITE request transmission. The non-precondition call flow defined by the 3GPP aims to provide flexibility against the absence of the pre-condition, but does not consider the interworking with the wireline network. Hence, the call setup varies in FIGS. 1 A, B and C. Naturally, the smooth call setup between the wired terminal and the wireless terminal is not expected.
FIG. 1A shows the call setup procedure in the wireline network, FIG. 1B shows the call setup procedure (the non-precondition) in the wireless network, and FIG. 1C shows the call setup procedure (the precondition) in the wireless network.
When the wireless terminal adopting the precondition attempts the call setup to the wired terminal, the wired terminal not adopting the precondition is likely to respond with error. Upon confirming the error, the wireless terminal may attempt the call setup by applying the non-precondition, if the non-precondition is supported. In the end, the call setup fails between the wireless terminal and the wired terminal because of the difference of the call flows of the wireline and wireless networks as shown in FIGS. 1 A, B and C.
Since the wireline network does not need to separate the resource reservation and the resource permission as in the wireless network, merely the single INVITE request transmission enables the communications. By contrast, while the wireless network requires two INVITE request transmissions in the non-precondition and requires one INVITE request transmission in the precondition, an UPDATE message transmission is needed in addition.
This difference causes out-of-service due to signaling state mismatch when the wireless network attempts the call to the wireline network or the wireline network attempts the call to the wireless network.
FIGS. 2 A and B depicts the call setup failure because of the signaling mismatch when the wireline network attempts the call setup to the wireless network.
In FIG. 2A, a wireline terminal 210 receives 200 Ok response at the point of receiving 180 Ringing response. While the wireline terminal 210 expects the 180 Ringing response from a wireless terminal 220 after sending the INVITE request, the wireline terminal 210 receives 200 Ok response (step 2: the wireline terminal 210 receives 200 Ok response at the point of receiving the 180 Ringing response).
The wireline terminal 210 may terminate the call setup procedure by regarding the response as error, or ignore the 180 Ring response and normally process the 200 Ok message.
In case where the wireline terminal 210 normally processes the 200 Ok response, the wireline terminal 210 sends Ack response and is ready to transmit a Realtime Transfer Protocol (RTP).
When the wireline terminal 210 sends the RTP, the RTP is discarded over the network because the wireless network and the wireless terminal have no the resource activation. That is, the wireline terminal 210 fails the RTP transmission (step 3: RTP transmission fails).
After receiving the Ack response from the wireline terminal 210, the wireless terminal 220 (non-precondition) expects the re-INVITE request from the wireline terminal 210 and enters a waiting mode without performing further operations.
Ultimately, the wireline terminal 210 and the wireless terminal 220 both stay in the waiting mode and fail the call setup because a timer expires (step 4: keep stand-by).
Referring to FIG. 2B, a wireless terminal 240 (the precondition) fundamentally enters the precondition mode. The INVITE request transmitted from an originating terminal (a wireline terminal 230) does not include an option tag precondition. When the correspondent does not support the precondition, the wireless terminal 240 basically transmits an error response.
When the INVITE request does not include the option tag ‘Required : Precondition’, the wireless terminal 240 may function as the non-precondition terminal and send the 200 Ok response. Even when the wireless terminal 240 operates as the non-precondition terminal, the call setup finally fails because of the above-mentioned problems (the steps 1, 2, and 3).
FIGS. 3 A and B illustrates the call setup failure resulted by the signaling mismatch in attempting the call setup from the wireless network to the wireline network.
In FIG. 3A, even when the INVITE request sent from an originating terminal 310 contains the option tag ‘Required : Precondition’, a wired terminal 320 cannot know the precondition (step 1).
Since the concept of the precondition is absent in the wireline network, the wired terminal 320 is unsupported and transmits the error response. Receiving the error response, the wireless terminal 310 may terminate the call setup procedure, or enter the non-precondition mode and retransmit the INVITE request, which results drawbacks in steps 2, 3 and 4 as follows.
In FIG. 3B, a wireless terminal 330 receives 180 Ringing response while expecting 200 Ok response. The wireless terminal 330 is expecting to receive the 200 Ok response from the correspondent 340 after the INVITE request transmission. On the contrary, the correspondent 340 sends the 180 Ringing response.
Upon receiving the 180 Ringing response, the wireless terminal 330 recognizes as error and terminates the call setup procedure. In this case, the call setup fails (step 2: the wireless terminal receives the 180 Ringing response while expecting to receive the 200 Ok response).
In step 2, the RTP transmission is feasible after the Ack response transmission in the communications between the wireline networks. Accordingly, the wired terminal 340, receiving the Ack response from the wireless terminal 330, is able to send the RTP and thus transmits the RTP first or waits for the RTP from the correspondent 330.
In so doing, since the wired terminal 340 does not acquire the bearer resource in the wireless network, the RTP will be dropped in the network and the wired terminal 340 enters the standby mode in the end.
However, because the wireless terminal 330 transmits the re-INVITE request, it is not likely that the call setup procedure is terminated (step 3 in case of stand-by or RTP transmission).
After the re-INVITE request transmission, the wireless terminal 330 expects to receive 180 Ringing response from the wired terminal 340. But, since the wired terminal 330 sent the 180 Ringing response in the first INVITE reception, it sends the 200 Ok response without no more 180 Ringing response.
When the wireless terminal 340 recognizes as error and ends the call setup procedure, the call setup fails (step 4: the wireless terminal receives the 200 Ok response while expecting the 180 Ringing response).
In FIGS. 2 and 3, the server sends the error response when only one terminal supports the precondition and thus the call setup fails. The error response can vary depending on the implementation of the terminal and a policy of a provider.
In relation to the error in FIGS. 2 and 3, the standard defines 420 Bad Extension response and 421 Extension Required response. The error response of FIGS. 2 A and B corresponds to the 421 Extension Required, and the error response of FIGS. 3 A and B corresponds to the 420 Bad Extension.
As shown in FIGS. 2 and 3, the call setup attempt from the wireline network to the wireless network is definitely infeasible, and the call setup attempt from the wireless network to the wireline network can degrade QoE due to the transmission and omission of the unexpected message in the call setup and the difference of the voice communication start points. What is worse, the call setup may fail. Disadvantageously, the signaling mismatch results the call setup failure.